I was not able to have an Android-Implementation that does not iterate trough the whole folder to find the first Item with the given name. The other thing is, that I don't have an IOS device to test the IOS-implementation.

Questions:

• Should I return IStorageFolder or IStorageFolder? ? => When nullable, which Excetions should be catched and which should be thrown (e.g getDirectoryHandle throws 4 different Exceptions. Should I catch all of them and return null?)
• Can I write tests for it or is it enough that I manually tested it?
• How to I resolve the build error?

• Should I return IStorageFolder or IStorageFolder? ? => When nullable, which Excetions should be catched and which should be thrown (e.g getDirectoryHandle throws 4 different Exceptions. Should I catch all of them and return null?)

We'll discuss that in an API review meeting soon and let you know, but I think the return type should be nullable. After all, even the Create{File/Folder}Async methods can return null.

• Can I write tests for it or is it enough that I manually tested it?

Platform specific code is unfortunately hard to test, and we don't currently have integration tests for storage, so manual testing should be ok here.

• How to I resolve the build error?

Adding new members to an interface is a breaking change, which is what the CI build reports here. However, IStorageFolder is marked with NotClientImplementable so we exceptionally allow breaking changes here as only platforms should implement it.

You should run nuke ValidateApiDiff to generate an API suppression file (but you might want to wait until we've properly reviewed the new API).

Diff for API review:

 namespace Avalonia.Platform.Storage {
 {
     [NotClientImplementable]
     public interface IStorageFolder : IStorageItem
     {
+        System.Threading.Tasks.Task<IStorageFile?> GetFileAsync(System.String name);
+        System.Threading.Tasks.Task<IStorageFolder?> GetFolderAsync(System.String name);
     }
 }

Thank you for your response. I'm still down to finish this MR so I will wait until the API review.

Notes from the API review meeting:

The API shape is good.

However, all platforms should behave the same, as much as possible.
For example, on the browser, there's an exception explicitly thrown at the start of the method (wrong copy/paste?), which should return null instead.

Thanks. I incorporated the browser change and updated the api-diff. It seems a bit weird because throwing vs. returning null is not everywhere strictly enforced when using the nullable operator. Should I just catch all Exceptions and return null? Event in the browser example, while I return null (if it is not a directory), there is still the potential to throw an Exception (wrong access, etc. ). But for the most part is shouldn't.

At @MrJul: Are you able to review my changes?

You can test this PR using the following package version. 11.3.999-cibuild0054385-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

Thanks. I incorporated the browser change and updated the api-diff. It seems a bit weird because throwing vs. returning null is not everywhere strictly enforced when using the nullable operator. Should I just catch all Exceptions and return null? Event in the browser example, while I return null (if it is not a directory), there is still the potential to throw an Exception (wrong access, etc. ). But for the most part is shouldn't.

We should model this on the BclStorageFolder/Item. Those are using Exists, which return false if any IOException or UnauthorizedAccessException occurs: we'll never throw in normal cases for this implementation (we still throw for OOM or other really unexpected errors).

Other implementations should match this behavior. Return null if the file can't be listed.
Bcl, Android and iOS all seem correct.
Browser needs swallowing the unauthorized access exception in the current catch block.

Other implementations should match this behavior. Return null if the file can't be listed.
Bcl, Android and iOS all seem correct.
Browser needs swallowing the unauthorized access exception in the current catch block.

Got it and also re-tested the browser implementation.

There where also some other JS-errors throws that I needed to suppress (NotFound and TypeMissmatch) to match the behavior of the other implementation.

You can test this PR using the following package version. 11.3.999-cibuild0054441-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]